Processing facilities in oil and gas, petrochemical, pharmaceutical, water/wastewater treatment, manufacturing, aerospace, travel, food, textile, film, hospital, leisure, foundry, agriculture, plastic, and printing industries utilize various process automation and safety systems in order to operate the plants safely and reliably to the optimal and maximum extent possible. Each system is manufactured by a specific vendor, utilizing specialized proprietary components. Although each system has its own unique history and characteristics, they all share a basic workload objective to ensure effective control of all disparate equipment within processing facilities in a cohesive fashion for improved safety, higher production rates, more efficient use of materials and energy, and consistent product quality.
The process automation technology has advanced rapidly since the mid-1980s; however, the latest systems still follow the traditional hierarchical structure of network layers, including field control network, plant control network, and plant information network. The main function of process control applications at the lowest network layer is to ensure a particular process doesn't vary by more than an allowed amount. The process control applications monitor the operation of associated parts of the process, identify unwanted changes, and initiate any necessary corrective actions. In the hierarchical structure, the control system at the middle network layer controls the overall production process and makes sure it continues to operate efficiently. At the plant network layer, the advanced control applications ensure optimum performance of processing units and improve the speed and accuracy of controlling a process. Reduced variability and increased predictability provide the operators a means to optimize the process by moving its operational setting closer to its constraints where the performance is likely to be higher. See W. Levine, The Control Handbook (CRC Press, 2010), incorporated herein by reference in its entirety.
The process automation systems run the gamut of age, technology, manufacturer, and family product series. As the equipment ages, components deteriorate, older technologies become superseded with newer products, manufacturers consolidate, product lines are eliminated, and technical support capabilities diminish. These reliability and obsolescence issues culminate in a broad range of challenges causing a huge escalating capital cost for managing the life cycle of these proprietary systems.
Most of the process automation and safety systems used in control applications are designed based on programmable logic controllers (PLC). FIG. 1 is a block diagram of a PLC hardware. A PLC includes a central processing unit (CPU), memory, input modules, output modules, and power supply. In FIG. 1, the arrows between blocks indicate the information and power flowing directions.
FIG. 2 is an illustration of a PLC operation cycle. There are four basic steps in the operation of a PLC, which continually take place in a repeating loop, including an input scan, a program scan, an output scan, and housekeeping. During the input scan, the PLC input modules detect the state of all input devices that are connected to the PLC. During the program scan, the PLC CPU executes the user created program logic. During the output scan, the PLC output modules energize or de-energize all output devices that are connected to the PLC. During the housekeeping step, the PLC CPU performs internal diagnostics and communications with programming terminals.
FIG. 3 is a block diagram of a PLC-based system architecture, which illustrates hardwired connections from field instruments up to human machine interface (HMI) consoles located at the Central Control Room (CCR). It spans through field junction boxes, marshaling cabinets, Input/Output (I/O) systems cabinets, controller system cabinets, Process Interface Buildings (PIBs), and a CCR rack room. The field instruments include pressure, level, flow, and temperature switches, valve position limit switches, motor status for pumps/compressors/mixers, start/stop command pushbuttons, field panel indicators, and start/stop and open/close output signals. Each field instrument is hard-wired to the closest junction box in the range of 10 to 50 meters. The junction boxes are enclosures used for cable interconnections between field devices and marshaling cabinets in PIBs and CCR. Each junction box includes terminal strips for cable terminations designed to suit environmental conditions in which the box will be installed, and to have certification of ingress protection code and hazardous area protection which conforms to the classified area.
Junction boxes can be hardwired using multicore cables to the closest marshaling cabinets inside PIBs or CCR in the range of 200 to 1000 meters. The function of the marshaling cabinet is to interface the incoming multicore cables with the I/O module system cables and to perform the cross wiring function. Cross wiring is necessary for the following reasons. Routing the input and output signals to the designated PLC is required. Mixing input and output field signals within the same incoming multicore cables and splitting them into consecutive and dedicated terminals for the associated I/O modules terminals is also required. In addition, the number of incoming field signals within multicore cables is often different from the number of channels per I/O module.
Each marshaling cabinet is hardwired using prefabricated multicore system cables to the designated system cabinets inside PIB/CCR in the range of 2 to 10 meters. The purpose of the system cabinet is to provide terminals to interface with the marshaling cabinets and to house the PLC power supply, I/O modules, controller CPU, communication modules, engineering work station, and the auxiliary power supply for powering the field instruments. The PIB is an explosive-proof building used to house and protect the system and marshaling cabinets from deteriorating effects of the weather. It is an unmanned and environmentally controlled building suitable to house delicate active electronics. Its location is carefully selected to withstand any unexpected field process explosion and be as close as possible to a large number of junction boxes in order to minimize cabling.
The CCR is a room serving as a central space where a large physical facility or physically-dispersed service can be monitored and controlled. The CCR for vital facilities are usually tightly secured and manned continuously. It has two major sections for a rack room and a control room. The function of the rack room is similar to the function of the PIB. The control room includes HMIs, engineering, and maintenance consoles, as well as auxiliary control panels for hardwired pull/push buttons for emergency and plant shutdown and annunciation panels for critical alerts. Consoles are interconnected through the plant information communication network. The CCR plant information communication network is extended by network segments to connect all PIBs that range from 1 Km to 10 Km in distance.
The PLC is designed based on a monolithic architecture, in which functionally distinguishable aspects such as the I/O system, the main control modules, and the control application, are not architecturally separate components but are all interwoven. This is similar to the mainframe computer architecture. The monolithic architecture does not allow for changing the design of certain aspects of the controller easily without having to overhaul the entire control application or to buy another controller altogether. For example, this happens when the controller becomes obsolete while the associated I/O system is still current and can be supported for several years to come.
A premature capital intensive investment of about 75% of the total cost of ownership is required for the replacement of the supported I/O system in order to replace the obsolete controller. Therefore, retaining the current I/O system and replacing only the associated obsolete controller is economically attractive. However, this option is not feasible due to either the lack of third party critical subcomponents or a new marketing strategy adopted by the vendor to surpass its competitors.
FIG. 4 is a block diagram of a distributed control system architecture, which illustrates a distributed control system 100 deployed in refining and petrochemical industries. Three different network layers include a field control network layer 110, a plant control network layer 120, and a plant information network layer 130. The architecture of distributed control system 100 is based on multiple proprietary or Ethernet-based local area field control networks called control segments 110, which extend from a central control room (CCR) 150 to process interface buildings (PIB)-1 160 and PIB-2 165, located close to processing facilities. Each control segment 110 connects two controllers 170 responsible for interfacing to field measurement and control devices through multiple junction boxes 180. The control segments 110 are interfaced to proprietary or Ethernet-based local area plant control network layer 120 located in the CCR 150, which connects multiple human machine interface (HMI) consoles 121, alarm management 122, a data historian 123, a data server 126, an advanced regulatory controller 124, and a multivariable controller 125. The data server 126 is connected to a proprietary or Ethernet-based local area plant information network layer 130 to provide near real-time process data to all nodes in the plant information network layer 130, including a processing unit controller 131, an advanced process controller 132, an inferential modeling unit 133 for predicting unmeasured process properties, and a lab information system 134 for calibrating the inferential models.
The controllers 170 perform basic control strategies including proportional, integral, and derivative (PID) continuous control loops and discrete sequence control to facilitate the basic operation, control, and automation requirements. The controllers 170 are distributed in the layer horizontally through the control segments 110. Each controller 170 is connected to its associated I/O racks 140 using a proprietary remote I/O communication (RI/OC) link. The controllers 170 are based on a monolithic architecture. The multivariable controller 125 of the plant control network layer 120 ensures minimum control loop interactions for achieving optimum performance of processing equipment. The advanced regulatory controller 124 provides feed forward, adaptive gain, and fuzzy logic control. See G. McMillan and D. Considine, Process/Industrial Instruments and Controls Handbook (McGraw-Hill, 1999), incorporated herein by reference in its entirety.
The processing unit controller 131 and the advanced process controller 132 are located above the plant control network layer 120. The processing unit controller 131 ensures optimum performance of processing units. The advanced process controller 132 improves the speed and accuracy of controlling a process by reducing variability and increasing predictability to provide operators with an optimized process by moving its operational setting closer to its constraints, where the performance tends to be higher. To achieve an optimum advanced process control solution, inferential models 133 are used to provide near real-time estimates of product qualities, which are otherwise available only through infrequent online or laboratory analysis. Inferential models are calibrated by using lab or on-line analyzer measurements to maintain their accuracy via the lab information system 134. See D. Coughanowr and S. LeBlanc, Process Systems Analysis and Control (McGraw-Hill, 2008), incorporated herein by reference in its entirety.
Today's competitive refining and petrochemical production environment is coupled with strict government laws and environmental regulations. As a result, there is a high demand on process industries to maximize valuable products and maintain high quality, and also minimize required energy consumption for survival and sustainability in the business. This challenging requirement mandates the utilization of agile and rigorous process control technology to increase productivity, improve quality, and minimize cost. See G. Coulouris, Distributed Systems: Concepts and Design (Addison-Wesley, 2011), incorporated herein by reference in its entirety.
In the 1980s, network-centric automation systems evolved resulting in distributed control system architectures. It is believed that higher performance can be achieved if greater amounts of data are shared throughout the enterprise using open systems. The drive towards openness in the 1980s gained momentum through the 1990s with the increased adoption of commercial off-the-shelf (COTS) components and Information Technology (IT) standards resulting in application-centric automation systems. Utilizing COTS components not only resulted in lower manufacturing costs for the supplier, but also decreased prices steadily for the end users. A major transition undertaken during this era was the development of Object Linking and Embedding for Process Control (OPC) technology and the move from the UNIX operating system to the Windows environment for everything above the controllers. Standard computer components from manufacturers, such as Intel and Motorola made it cost prohibitive for DCS suppliers to continue making their own workstations and networking hardware. The primary business of DCS suppliers, for years, had been the supply of large amounts of proprietary hardware, particularly controllers and associated I/O racks.
The computing power of the main control module is limited and not suitable for computing intensive control strategies. As a result, proprietary application modules are used for implementing advanced regulatory and multivariable control strategies at the plant control network layer. The plant control layer is proprietary and cannot accommodate third party applications. Hence, the standard rigorous solutions for advanced process control have been implemented at the plant network layer, utilizing near real-time process data provided by the OPC data server. The interaction among the heterogeneous process control applications across all network layers can be implemented using a client-server communication model.
The drive towards collaboration among applications in the 1990s gained momentum through the 21st century with the increased adoption of object-centric protocol for the interface among web applications using client-server communication models. This communication model works well for a system architecture in which there is a centralized server in each network layer. At the field control network layer, the process data is centralized within each associated controller. At the plant control network layer, the process data is centralized within a data server, which provides real-time process data to proprietary nodes from the same system vendor. At the plant network layer, the process data is centralized within an Object Linking and Embedding for Process Control (OPC) data server to provide near real-time plant data to nodes from different manufacturers. However, this model precludes deterministic communications and is not effective for exploiting the processing facilities to achieve maximum yield, since the information is being generated at multiple nodes and the client does not know when new information is available. See C. Pereira and L. Arro, Distributed Real-Time Embedded Systems: Recent Advances, Future Trends and Their Impact on Manufacturing Automation, Annual Reviews in Control, 31 (2007), pp. 81-92, incorporated herein by reference in its entirety.